[アップデート] AWS Backupがボールトのロックをサポートしました

#AWS Backup
#AWS
Takuya Shibata
2021.10.09
この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
しばたです。
本日AWSよりAWS Backupに新しいバックアップ保護レイヤーとなる「Vault Lock」が追加されたと発表されました。
https://aws.amazon.com/jp/about-aws/whats-new/2021/10/aws-backup-backup-protection-aws-backup-vault-lock/
初見ではちょっと分かりにくい内容だったため本記事で軽く解説しようと思います。
 どういうこと？元々AWS Backupで取得される各種バックアップはAWSサービスの管理下にありユーザーが直接削除・改変できない様になっています。(AWSのドキュメント上ではimmutableであるという表現がされている)
ただし、AWS BackupのAPIを介した操作であれば正当な操作であるためバックアップの削除は可能です。

Vault LockではこのAWS BackupのAPIからも削除できない様にバックアップを保護し、バックアップルールで指定した保持期間の間は必ずバックアップが維持されることを保証します。
先述のアナウンスによればVault LockによりボールトをあたかもWORM(Write-Once-Read-Many)メディアの様に扱えるとあります。

この表現を借りて「 Vault LockはボールトをWORMメディアにする機能 」と考えておけばとりあえず問題ないでしょう。
 Vault Lockの動機AWSとしてはこのVault Lockを
Securities and Exchange Commission (SEC) rule 17a-4 (f)
Commodity Futures Trading Commission (CFTC) 1.31 (b)-(c)
などの特定のコンプライアンス要件を満たすための機能として使いたい様です。
例えばSEC rule 17a-4では電子ストレージメディアは
(A) Preserve the records exclusively in a non-rewriteable, non-erasable format;

(B) Verify automatically the quality and accuracy of the storage media recording process;

(C) Serialize the original and, if applicable, duplicate units of storage media, and time-date for the required period of retention the information placed on such electronic storage media; and

(D) Have the capacity to readily download indexes and records preserved on the electronic storage media to any medium acceptable under this paragraph (f) as required by the Commission or the self-regulatory organizations of which the member, broker, or dealer is a member.
であることが要求され、実質WORMメディアを必須としています。

ただしSEC rule 17a-4ではWORMメディア以外の要件もあり、現時点では開発者ガイドに
Note

AWS Backup Vault Lock has yet to receive a third-party assessment for SEC 17a-4(f) and CFTC.
とある様に まだ SEC rule 17a-4およびCFTC 1.31を満たしていないのでご注意ください。

(とはいえ、そう遠くないうちに要件を満たすと思いますが)
 試してみたVault Lockがどういうものか分かったのでここからは実際に試してみます。

ただし、詳細は後述しますが現時点はVault Lockのすべての機能を確認することはできませんでした。
 0. 前提条件Vault Lockは現時点ではREST APIおよびAWS CLIからのみ設定可能となっています。

機能の性質からしてマネジメントコンソールからの操作は今後もできない予感がします...
また、AWS CLIもv2はまだ非対応でv1(Ver.1.20.57以降)のみ対応しています。

こちらはそのうちAWS CLI v2でも対応してくれると思います。

AWS CLI v2 (Ver.2.2.45以降)でも対応されました。
今回はAWS CLI Ver.1.20.58 on Bashな環境で動作確認をしました。
$ aws --version
aws-cli/1.20.58 Python/3.10.0 Linux/5.10.16.3-microsoft-standard-WSL2 botocore/1.21.58
AWS環境は私の検証用アカウントで東京リージョンを使用してます。
 1. 初期状態まずは最初にテスト用のボールト(my-worm-backup-vault)を作っておきます。

こちらはマネジメントコンソールからこんな感じで作っています。
何の変哲もない通常のボールトです。
この状態でaws backup describe-backup-vaultコマンドを実行してボールトの情報を確認するとLockedという新しいプロパティが増えていることがわかります。
$ aws backup describe-backup-vault --backup-vault-name my-worm-backup-vault
{
    "BackupVaultName": "my-worm-backup-vault",
    "BackupVaultArn": "arn:aws:backup:ap-northeast-1:xxxxxxxxxx:backup-vault:my-worm-backup-vault",
    "EncryptionKeyArn": "arn:aws:kms:ap-northeast-1:xxxxxxxxxx:key/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "CreationDate": 1633759420.909,
    "CreatorRequestId": "07741c87-d3d0-4850-844c-95419edd682b",
    "NumberOfRecoveryPoints": 0,
    "Locked": false
}
 2. Vault Lockを有効にするVault Lockを有効にするにはaws backup put-backup-vault-lock-configurationコマンドを使います。

このコマンドには以下のパラメーターを渡します。
backup-vault-name : 対象ボールト名
changeable-for-days : (optional) クーリングオフ期間 (日)
min-retention-days : (optional) 最小保持期間 (日)
max-retention-days : (optional) 最大保持期間 (日)
はじめにchangeable-for-daysについて説明すると、このパラメーターで指定した期間の間は保持期間の設定を見直したりVault Lock自体を無効にするいわゆる クーリングオフ が可能な期間となります。

このパラメーターは最低3日指定する必要がありクーリングオフ期間を超えると設定変更ができなくなるそうです。

本日リリースされた機能なので実際にクーリングオフ期間を超えた挙動は確認することは出来ませんでした...
ちなみにこのパラメーターを指定しない場合はいつでも設定変更が可能(いつでもクーリングオフ可能)になります。
そしてVault Lockの設定自体はクーリングオフ期間に関係なくコマンド実行直後から有効となります。
次にmin-retention-daysとmax-retention-daysについてはバックアップを保持する最小、最大期間となります。

これらのパラメーターを設定すると、以後この保持期間に収まらないバックアップジョブはエラーとなります。
Backup job failed because the lifecycle is outside the valid range for backup vault.
(Vault Lock設定後は保持期間に矛盾のあるジョブはエラーとなる)
なお、Vault Lockの設定前に取得されているバックアップは影響を受けません。
今回は開発者ガイドにある例をそのまま設定してみます。
$ aws backup put-backup-vault-lock-configuration \
        --backup-vault-name my-worm-backup-vault \
        --changeable-for-days 3 \
        --min-retention-days 7 \
        --max-retention-days 30
エラー無く完了すればOKです。
あらためてaws backup describe-backup-vaultコマンドでボールトの内容を確認すると"Locked": trueとなりMinRetentionDaysやMaxRetentionDaysが増えていることがわかります。

LockDateがクーリングオフの終了時刻となり、開発者ガイドだとISO8601形式の日付だったのですが実際にはUNIX Timeで返されています。
$ aws backup describe-backup-vault --backup-vault-name my-worm-backup-vault
{
    "BackupVaultName": "my-worm-backup-vault",
    "BackupVaultArn": "arn:aws:backup:ap-northeast-1:xxxxxxxxxx:backup-vault:my-worm-backup-vault",
    "EncryptionKeyArn": "arn:aws:kms:ap-northeast-1:xxxxxxxxxx:key/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "CreationDate": 1633759420.909,
    "CreatorRequestId": "07741c87-d3d0-4850-844c-95419edd682b",
    "NumberOfRecoveryPoints": 0,
    "Locked": true,
    "MinRetentionDays": 7,
    "MaxRetentionDays": 30,
    "LockDate": 1634022477.087
}
Vault Lockを設定した後は保持期間中にバックアップ(復旧ポイント)を削除しようとしても以下の様にちゃんとエラーになり保護されます。
RecoveryPoint cannot be deleted or updated (Backup vault configured with Lock).
もちろん削除だけでなく保持期間の変更といった「更新」もできません。
 3. Vault Lockの設定変更・削除クーリングオフ期間中であればVault Lockの設定を変更できます。
変更はaws backup put-backup-vault-lock-configurationを実行しなおすだけでOKです。

クーリングオフ期間も再設定されます。
Vault Lock設定の削除はaws backup delete-backup-vault-lock-configurationを実行してやります。
$ aws backup delete-backup-vault-lock-configuration --backup-vault-name my-worm-backup-vault
こちらもエラー無く終了すればOKです。

aws backup describe-backup-vaultコマンドで"Locked": falseに戻っていることが確認できます。
$ aws backup describe-backup-vault --backup-vault-name my-worm-backup-vault
{
    "BackupVaultName": "my-worm-backup-vault",
    "BackupVaultArn": "arn:aws:backup:ap-northeast-1:xxxxxxxxxx:backup-vault:my-worm-backup-vault",
    "EncryptionKeyArn": "arn:aws:kms:ap-northeast-1:xxxxxxxxxx:key/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "CreationDate": 1633759420.909,
    "CreatorRequestId": "07741c87-d3d0-4850-844c-95419edd682b",
    "NumberOfRecoveryPoints": 0,
    "Locked": false
}
 最後に以上となります。
特定のコンプライアンス要件向けの機能ですので設定する機会はそう多くないかもしれません。
ただ、ボールト側でデータ保護を強制できる仕組みですので単純に誤操作による削除を防ぐ仕組みとして導入するのもアリだと思います。

必要に応じて導入を検討すると良いでしょう。